Interface controls for use in a field device management system

ABSTRACT

An interface control for use in a field device management system coupled to a set of smart field devices automatically performs functions related to communication between a device, a database and a user of the management system and functions related to interfacing with a user in a manner which is transparent to the software application running on the management system. The control monitors a device, or a block or a parameter of a device, displays information pertaining to the device, block or parameter to a user, receives information pertaining to such device, block, or parameter from a user and the device, automatically updates the displayed information, and implements changes to the device block or parameter specified by the user. A timeline control specifies a time at which past, present or future configurations of devices, blocks, parameters, or other data associated with one or more devices is to be displayed.

RELATED APPLICATION

This application is a continuation of U.S. patent application Ser. No.08/599,371, entitled "System and Method for Managing a TransactionDatabase of Records of Changes to Field Device Configurations," filedFeb. 6, 1996.

TECHNICAL FIELD

The present invention relates generally to management systems havingapplications that manage "smart" field devices within a process or aplant and, more particularly, to automatic controls used by suchmanagement systems which control functions related to interfacingbetween an application, a user, a database, and smart field deviceswithin a process.

BACKGROUND ART

Typically, process plants (such as chemical refinery plants and drugmanufacturing plants, for example) include many field devices whichcontrol and measure parameters within the process. Each field device maybe a control device (such as a flow valve controller), a measurementdevice (such as a temperature gauge, pressure gauge, flow meter, etc.)and/or any other device that affects or determines a value associatedwith a process. Until the past decade or so, field devices havetypically been rather simple devices which were controlled eithermanually or electronically and which produce output readings eitherelectronically or on a gauge connected to the device. However, thesedevices typically only provide limited information to a controller suchas analog signals pertaining to the readings or measurements made bythese devices.

More recently, so called "smart" field devices have been developed.Smart field devices are capable of communicating with a processcontroller and/or a management system associated with the device.Typical smart field devices are capable of transmitting an analog signalindicative of the value associated with the device, for example, ameasurement value, and of storing and also digitally transmittingdetailed device--specific information, including calibration,configuration, diagnostic, maintenance and/or process information. Somesmart devices may, for example, store and transmit the units in whichthe device is measuring, the maximum ranges of the device, whether thedevice is operating correctly, troubleshooting information about thedevice, how and when to calibrate the device, etc. Furthermore, a smartfield device may be able to perform operations on itself, such asself-tests and self-calibration routines. Exemplary smart devicesinclude devices which follow the HART (Highway Addressable RemoteTransducer) protocol (HART devices), the Fieldbus protocol (Fieldbusdevices), the Modbus protocol, and the DE protocol. However, other smartdevice protocols may exist or be developed in the future to supportdifferent types of smart devices.

Currently, every conventional and smart device is capable of performingone or more specific input and/or output functions with respect to aprocess. An input function is any function which measures or reads avalue associated with a process, such as the function performed by atemperature or pressure measurement device. An output function is anyfunction that changes something within a process, such as the functionsperformed by a valve or flow controller. Furthermore, some smartdevices, such as Fieldbus devices, can perform control functions whichare functions associated with the control of a process. Each input,output and control sub-function performed by a device is referred to asa "block." By definition, therefore, each device includes at least oneand maybe more blocks. Fieldbus devices usually include multiple blocks(e.g., one or more input, output, and control blocks), and, while HARTdevices do not include blocks per se, the contents of a HART device maybe conceptualized as constituting one and only one block.

Each block and, therefore, each device includes one or more"parameters." A parameter is an attribute of a block whichcharacterizes, affects or is somehow otherwise related to the block.Parameters may include, for example, the type of the block, the maximumoperating or measurement range of a block, the mode of a block, thevalue of a block measurement, etc.

Likewise, each parameter has one or more properties associatedtherewith, and each of those properties defines or describes theinformation within the parameter. For example, the temperature parameterof a temperature measuring device has a label property which stores thename of the parameter (e.g., "temperature"), a value property whichstores the value of the parameter (e.g., the actual measuredtemperature), and a units property which stores the units in which thetemperature PATENT 06005/33102 value is expressed (e.g., degreescentigrade or degrees fahrenheit). A device or a block configurationcomprises a set of values for each of the properties of each of theparameters associated with a device or a block.

As noted above, smart field devices are developed so that communicationtherewith must be performed in one of several available protocols (theHART and Fieldbus protocols, for example). These protocols allow devicemanufacturers to provide device-specific types of information for adevice and, of course, the particular types of information are differentfor each type of smart field device. Consequently, these protocols arecomplex and difficult to use in device programming. More particularly,some of these protocols do not provide a completely consistent methodfor communicating with every smart device conforming thereto. Instead,these protocols, such as the HART protocol, merely provide a way fordevice manufactures to specify what information is available from eachsmart field device and how to retrieve that information.

Communication with smart devices has been simplified to some extent withthe advent of device description languages (DDL) and device descriptionswhich are provided by the manufacturers of smart field devices. A DDL isa human-readable language that provides a protocol for describing thedata available from a smart device, the meaning of the data associatedwith the smart device and retrieved therefrom, the methods available forimplementation of the smart device, the format for communicating withthe smart device to obtain data, user interface information about thedevice such as edit displays and menus, and information for handling orinterpreting other information pertaining to a smart device.

DDL source files comprise human-readable text written by devicedevelopers. These files specify all the information available about adevice between the device arid a bus or a host to which the device isconnected. Basically, in developing a DDL source file for a device, adeveloper uses the DDL language to describe core or essential parametercharacteristics of the device as well as to provide group-specific, andvendor-specific definitions relating to each block, parameter, andspecial feature of a smart device.

A DDL source file is compiled into a binary format to produce amachine-readable file known as a device description (DD) which can beprovided to a user by the device manufacturer or a third-party developerto be stored in a host system, such as a management system. In somecases, for example in Fieldbus devices, DDL source files may be storedin a smart device and transferred from the smart device to a hostsystem. When the host system receives a DD object file for a smartdevice, it can decode and interpret the DD to derive a completedescription of the interface with the device.

DDS is a general software system developed and provided byFisher-Rosemount Systems, Inc. and/or Rosemount, Inc. for automaticallydecoding and interpreting the DD's of smart devices. More particularly,DDS is a library of routines which, when called by a host, interpretsthe DD of a smart device to provide the host with information pertainingto the smart device, including information pertaining to: (1) the setupand configuration of the smart device; (2) communication with the smartdevice; (3) user interfaces; and (4) methods available for use inconjunction with the smart device. One extremely useful application ofDDS is in providing a consistent interface between a host system and oneor more smart devices having associated DDL source files (andcorresponding DD object files).

Although DDS, DDL and DD's are generally known in the art, moreinformation pertaining to the specific function and format of DDL's, andof Fieldbus DDL in particular, can be found in the InterOperable SystemsProject Foundation's manual entitled "InterOperable Systems ProjectFieldbus Specification Device Description Language" (1993). A similardocument pertaining to the HART DDL is provided by the HART foundation.

A management system is a system which interacts with one or more smartfield devices to read any of the device, block, parameter, variable, orconfiguration information associated with those devices. Typically, amanagement system comprises a personal computer having appropriatecommunication ports which allow it to interconnect to, communicate with,and reconfigure a smart device. Management systems may be on-line, thatis, have a hard-wired or other permanent connection with a smart device,or may be portable and capable of being periodically connected to asmart device to reconfigure that smart device.

Management systems typically perform a wide variety of functions withrespect to smart devices within a system. For example, managementsystems may be used to provide users with information (e.g., values ofvariables or parameters) pertaining to the state of a process and toeach of the smart field devices associated with or connected to theprocess. Management systems may also be used to enable a user to monitora process and control the process by reconfiguring smart devices withinthe process as necessary.

The software routines which are used to perform functions within amanagement system using features provided by the system are typicallyreferred to as applications. Typically, management systems implementapplications provided by individual smart device manufacturers toimplement changes on, and read data from, a particular smart device. Asa result, various applications within a management system often do notshare a common or consistent interface, and the transition from oneapplication to another is therefore cumbersome and time-consuming.Further, smart device configuration data, configuration logs, and smartdevice diagnostic data created and stored by different applications aredecentralized and cannot be cross-referenced because this data may bestored in diverse formats, in different databases and, in some cases, inproprietary formats. Consequently, tasks that could be common to eachdevice within a system must be duplicated in separate applications.

A management system which implements such separately developedapplications typically has no way to view information pertaining to allthe smart devices in a plant or a process simultaneously because theapplications for each device must be run separately. Furthermore, it isdifficult for users to write applications that provide a comprehensiveview of data pertaining to multiple, different devices in a processbecause users typically do not have a great familiarity with DDS or withthe DDL and DD's associated with each of the devices within a process.Even if a user does have such familiarity, such applications aretime-consuming and expensive to develop and must be updated each time anew smart device is added to the system.

Another cumbersome aspect of developing applications for managementsystems is programming the application to perform the numerous tasksrelating to and necessary for communication between a user and eachsmart device within a system. A developer not only must be attentive todetails involving how to communicate with each separate device, but thatdeveloper must also pay particular attention to how information ispresented to a user via, for example, a display. This task is made moredifficult because typical applications do not use consistent userinterface protocols. Instead each of the interface functions requiresmuch programming time and effort, which must be repeated each time a newsmart device is added to the system.

Still further, applications typically allow a user to view a currentconfiguration of a device, block, or parameter within a process, butthose applications do not allow the user to view past configurations orto display multiple configurations simultaneously to compare suchconfigurations.

SUMMARY OF THE INVENTION

This invention is related to interface controls for use in a managementsystem capable of being coupled to one or more smart field devices. Theinterface controls perform consistent communication and interfacingfunctions between an application, a user interface and multiple fielddevices coupled to the system so that no new programming is necessary tocommunicate with and display information pertaining to newly added smartdevices. The interface controls may use a communication network whichrelies on a hierarchy of information related to one or more DDL'sassociated with one or more smart devices connected to the system. Thecommunication network uses this hierarchy to call, access informationfrom, and communicate with a DDS associated with the one or morecategorized DD's, smart devices connected within a system, and/or adatabase associated with the system.

Controls according to the present invention use the communicationnetwork to perform functions related to communication between a deviceor a database and a user in a manner which is transparent toapplications running on the management system. Preferably, such controlsmonitor a device, block, or parameter; display information pertaining tothe device, block or parameter to a user; receive information pertainingto such device, block, or parameter from a user; automatically updatethe display in response to changes to the device, block or parameter;and/or implement changes specified by the user or the application, allin a continuous or semi-continuous manner.

Preferably, a control is also provided to display historical informationpertaining to a device, block, parameter, or any other constructassociated with one or more devices in a system. Particularly, atimeline control can be used to specify past, present and future timesfor which configurations of devices, blocks, parameters, or other dataassociated with devices can be displayed. Timeline controls may also beused to display multiple configurations simultaneously.

Using such controls, an application for a management system can bedesigned even by an application designer who has no knowledge of thesteps necessary to perform these communication tasks, the particularkinds of devices that are available to, or are attached to the system,or the different protocols associated with each of the smart devicesconnected to the system.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram illustrating the interconnections between aprocess, a distributed control system and a management system;

FIG. 2 is a block diagram of the management system of FIG. 1 having userinterface controls which operate according to the present invention;

FIG. 3 is an upper hierarchy of object information used by a devicecommunication network according to the present invention;

FIGS. 4A-4C are a lower hierarchy of object information used by a devicecommunication network according to the present invention;

FIG. 5 illustrates the interface control block of FIG. 2;

FIG. 6 is a flowchart illustrating the initialization steps associatedwith a control constructed according to the present invention;

FIGS. 7-13 are flowcharts illustrating the operation of controlsaccording to the present invention;

FIG. 14 is a screen display which can be generated by a set of devicecontrols according to the present invention;

FIG. 15 is a screen display which can be generated by a set of parametercontrols according to the present invention;

FIG. 16 is a screen display which can be generated by a set of blockcontrols according to the present invention;

FIG. 17 is a screen display which can be generated by a set of timelineand parameter controls according to the present invention; and

FIG. 18 is a flowchart illustrating programming for reconstructing anexpected device state from a transaction database.

DETAILED DESCRIPTION

FIG. 1 illustrates a management system 10, referred to hereinafter as aField Management Solutions system (an FMS system), interconnected with aprocess 12, a distributed control system (DCS) 14 which controls theprocess 12, and a further management system such as another FMS system15. The process 12 may comprise any desired type of process, such as amanufacturing or refinery, process, etc., and is illustrated asincluding four smart field devices, including three HART devices 16, 18and 20 and one Fieldbus device 22, and a conventional (i.e., non-smart)device 24. The devices 16, 18, 20, 22 and 24 are controlled in anydesired manner by the DCS 14

Generally, the FMS system 10 is a PC-based software tool that includesapplications which perform field-device management tasks. The FMS system10 integrates device management for each of the devices within theprocess 12 by helping users to, for example, configure, calibrate,monitor and troubleshoot any and all of the smart field devicesassociated with the process 12.

The FMS system 10, which may comprise any type of computer- ormicroprocessor-based system, may include a display 30, a printer 31, akeyboard 32 and a mouse 34 connected to an operating system and CPU 36.A memory 38 having an FMS database 40 is coupled to the operating systemand CPU 36. The memory 38, including the FMS database 40, storessoftware and data used by the FMS system 10 in performing tasks relatedto displaying information to a user via the display 30 or the printer 31and communicating with the smart devices 16, 18, 20 and 22. In addition,the FMS database 40 stores device-related information which is notavailable from the smart devices, for example, information pertaining topast configurations of the devices, information pertaining to off-linedevices, such as off-line smart devices and conventional devices, andinformation pertaining to service notes including when the next serviceis needed; who performed service procedures; any favored replacementdevices, etc. Data pertaining to off-line smart devices may be storedwithin the database 40 in a format identical to the format in which thatdata is actually stored within the off-line devices so that, to the FMSsystem 10, off-line devices appear to be available through the database40 in the same way they would be available if those devices were online.

The smart devices 16 and 18 are on-line devices which are connected tothe FMS system via a communication line 42 and a modem 44. The smartdevice 22 is an on-line device which is connected to the FMS system viaa Fieldbus interface 45. The smart device 20 is an off-line device whichis not permanently connected to the FMS system 10. However, the smartdevice 20 may communicate with the FMS system 10 via a hand--heldcommunicator and/or secondary (laptop) FMS 46 which may be periodicallyconnected to the device 20 and/or any of the other smart devices to readdata from, and write data to, the device 20 and/or the other smartdevices. Thereafter, the hand-held communicator and/or secondary FMS 46may be connected to the FMS system 10 to upload data pertaining to thesmart device 20 and/or any other smart devices to which it was attachedand store such data in the FMS database 40.

If desired, the operating system and CPU 36 of the FMS system can beconnected through, for example, an ethernet communication link 48 and/orother network link to the DCS 14 and other FMS systems, for example, theother FMS system 15.

FIG. 2 illustrates the interconnections between various component partsof the FMS system 10, including hardware and software components, andwill be used to describe how the various software components stored inthe memory 38 of the FMS system 10 interact with each other, with thedisplay 30, the printer 31, the keyboard 32, the mouse 34, the FMSdatabase 40 and the smart devices within the process 12. It isunderstood that the software components of the FMS system 10 are storedin the memory 38 and are run on the operating system and CPU 36.

The FMS system 10 preferably operates in a Microsoft Windows environment(such as a Windows 95™ environment) and, therefore, includes a standardWindows operating system 49, which is used to display data andinformation on the display 30 and the printer 31 and to retrieve dataand information from the keyboard 32 and the mouse 34. Thus, informationprovided to, or retrieved from, the Windows operating system 49 ispreferably provided in a standard Windows call format of any desiredtype, as is known to those skilled in the art. However, the FMS system10 could be implemented according to the present invention using anyother desired Windows-based or non-Windows-based interface format(whether or not a graphical user interface) including, for example,MacIntosh, Xwindows or IBM DOS formats.

The FMS system 10 includes a set of FMS applications 50 comprising coreapplications 52 and add-on applications 54. The core applications 52 areessentially programs written by the FMS system provider to performpredetermined and frequently used operations. The add-on applicationsare applications which are developed by a user or a third-partydeveloper and imported to the FMS system 10 to perform customizedfunctions.

As used hereinafter, an application refers to any software routineimplemented by the FMS system 10 which displays to a user informationpertaining to or about the process 12 or one or more devices, blocks,parameters, or other information associated with the devices connectedto, or associated with, the FMS system 10, and/or which allows a user toreconfigure one or more of the devices associated with or connected tothe FMS system 10. The information used by an application typically iseither stored in, or developed by, the smart devices within the process12, or is stored in the FMS database 40.

Thus, for example, the FMS system 10 may include core or otherapplications which allow a user to interact with the data within the FMSdatabase 40 and/or the smart devices within the process 12 to view thepresent state of one or more of the devices within the process 12, tochange the configuration of one or more of the smart devices within theprocess 12, to view multiple devices in a simultaneous or sequentialmanner, to perform common smart device control and configurationfunctions, to run browsers that locate devices on the network, tomonitor the status of devices and generate alarm lists, and to implementdevice calibration and testing routines.

During operation of the FMS system 10, a user selects one or more of theapplications for execution. The selected application is identified inFIG. 2 as the current application or applications 56. Because multipleapplications may be executed simultaneously by the FMS system 10, theremay be multiple current applications 56. Any current application 56 mayinterface directly with the Windows operating system 49, an interfaceblock 58, a digital control interface (DCI) 60 and an FMS databaseinterface 62. If desired, the current application 56 can also interfacewith an Open DataBase Connectivity (ODBC) block 64 (a well-knownMicrosoft database application interface (API) system that enablescommunication with nearly all databases) and a server network 65. Formany applications, however, such connections are not necessary ordesirable. Furthermore, any current application 56 may indirectlyinterface with the Windows operating system 49, the smart devices withinthe process 12, and the database 40 via the interface block 58.

The interface block 58 is essentially a software package having, forexample, specifically configured Windows custom controls, OCX controlsor VBX controls, which automatically perform functions relating to thecommunication of particular, frequently used information between acurrent application 56, the smart devices within the process 12, thedatabase 40, and a user interface 65 comprising the Windows operatingsystem 49, the display 30, the printer 31, the keyboard 32, and themouse 34. The interface block 58 can be used by a current application 56to perform these interfacing functions without the application designerknowing the specifics of the protocols involved therewith. As a result,the interface block 58 enables an application to be designed more easilyand provides a consistent user interface.

Preferably, current application(s) 56 and the interface block 58interface and communicate with the smart devices within the process 12,other FMS systems or distributed control systems and/or the database 40through the DCI 60 and a server network 66 comprising servers 68 and 70.While typically the server network 66 will be located in, and associatedwith, the FMS system 10, the dotted line between the DCI 60 and theservers 68 and 70 in FIG. 2 indicates that the DCI 60 can also accessserver networks of other FMS systems through, for example, the ethernetconnection illustrated in FIG. 1.

Essentially, the DCI 60 is a convenience layer comprising a library ofroutines which perform functions necessary for communicating with, andretrieving data from, and performing other functions pertaining to thedatabase 40, the smart devices associated with the process 12 and/orother FMS systems. In operation, the DCI 60 converts commands andmessages sent from the current application 56 and the interface block 58into a format recognized and used by server network 66 and, likewise,converts data provided by the server network 66 into a form recognizedand used by the current application 56 and the interface block 58.

While the DCI 60 can use any desired protocol to perform thesecommunication functions, the DCI 60 preferably uses an object-orientedprotocol and, most preferably, uses an object linking and embeddingprotocol such as the Object Linking and Embedding (OLE) protocoldeveloped and documented by MicroSoft, Inc. The MicroSoft OLE (2.0)protocol is used in the MicroSoft Windows 95™ operating system and iswell-known in the art.

Generally, an object-oriented protocol is a programming paradigm whichmodels the world as a collection of self-contained objects that interactby sending messages. Objects include data (a state) and methods(algorithms) that can be performed on the data. In addition, objects arerelated to one another through an interface connection and maycommunicate with other objects in the hierarchy through messages. Whenan object receives a message, it responds by using its own methods whichare responsible for processing the data in that object and sendingmessages to other objects to perform specific tasks and possibly returnappropriate results.

Because the DCI 60 communicates with the server network 66 through anOLE hierarchy, the DCI uses standard OLE procedures or calls relating toreading and writing values of OLE objects, enumerating a set ofenumerated values in an OLE object, getting and setting properties inOLE objects, calling and implementing methods of OLE objects andretrieving property data stored in the OLE collection objects inconjunction with OLE Item methods (a particular type of OLE method).However, other OLE procedures can be implemented by the DCI 60 on OLEobjects to communicate with the server network 66.

As described in more detail below, the particular OLE hierarchy which ispreferably used by the FMS system 10 is an OLE object hierarchy whichhas been developed to categorize all of the different types ofinformation and the interrelationships between the different types ofinformation available for, or used by, each of the different DDL'sassociated with each of the DD's which, in turn, are associated with thedevices within the process 12 being serviced by the FMS system 10. Thisdetermined hierarchy defines a set of OLE objects, each of which storesa particular set of properties as defined by the hierarchy and aparticular set of methods which can be used to manipulate the propertydata and to communicate with other OLE objects according to therelationships defined by the hierarchy. This hierarchy will be discussedin more detail in conjunction with FIGS. 3 and 4A-4C.

Essentially, the DCI 60 communicates with the server network 66 as ifall the OLE objects identified for the determined hierarchy exist withinthe memory of the server network 66. The DCI 60 implements a simple setof calls necessary for communicating with the OLE objects in the OLEprotocol. In reality, however, the data and methods of each OLE objectare not actually stored or placed in the memory of the server network 66until a call, such as a read or write call, is sent to the servernetwork 66 for such OLE object by, for example, the DCI 60, the DDS 72,the smart device communication network 74, or the FMS database interface80. At that time, the server network 66 recognizes that the data andmethods pertaining to the OLE object must be retrieved and stored inmemory associated with one of the servers 68 or 70 and automaticallyperforms the functions necessary to retrieve the data and methods ofthat OLE object.

When the server network 66 receives a call. relating to the reading orwriting of data or methods within one of the OLE objects stored in itsmemory, the server network 66 returns the requested information orperforms the requested function to the OLE object data according to itsstored routines so as to read data from, and write data to, the OLEobject, the DDS 72, the smart devices within the process 12 and the FMSdatabase 40.

Likewise, the DCI 60 recognizes or receives changes in OLE objectsstored within the memory associated with the server network 66 andperforms functions based thereon to implement communication with thecurrent application 56 and the interface block 58. The device server 68is essentially a set of software routines which have a specifiedcorrespondence with the set of OLE objects in the determined OLEhierarchy. These routines are specifically developed to communicate witha DDS 72, a smart device communication interface 74, and the OLE objectsof the defined hierarchy. Such routines may, for example, transmit,retrieve, and change particular types of data and information storedwithin, or available from, the smart devices within the process 12and/or from DD's (which are files) associated with the smart deviceswithin the process 12. Likewise, the database server 70 is essentially aset of software routines associated with the OLE objects in thedetermined OLE hierarchy. These routines communicate with the DDS or API72 and/or an FMS database interface 8CI to, for example, transmit,retrieve, or change particular types of data and information storedwithin, or available from, the FMS database 40 and/or from the DD'swhich are associated with the smart devices for which data is stored inthe FMS database 40. As indicated in FIG. 2, the DD's used by the DDS 72are stored in a device description library 76 coupled to the DDS library72.

The routines of the servers 68 and 70 are associated with each of theOLE objects in such a way that the routines which perform the particularread functions required for retrieving the data of an OLE object fromthe DDS 72, from smart devices, or from the database 40 areautomatically implemented by a request for such data from the DCI 60.Likewise, the routines of the servers 68 and 70 are associated with eachof the OLE objects in such a way that the routines which perform theparticular writing functions required for changing the configuration ofsmart devices or storing information in the database 40 areautomatically implemented by a request made by the DCI 60 to write suchdata in the OLE object.

These server routines are simple, straightforward, and easy to write bythose skilled in the art and are not, therefore, provided herein.However, those familiar with OLE and DDL's can create such routines in astraightforward manner using any desired programming language.

Generally, to retrieve specific data from, or pertaining to, one of theon-line devices of the process 12, the server 68 asks the DDS 72 for thespecific data. If that data is stored in the DD for a smart device, theDDS 72 then consults the DD for the referenced device or the DDassociated with a block of the referenced device and returns therequested data to the server 68.

If the specific data was available from the DD, the server 68 stores andmaintains that data in the OLE object to which the retrieved data isrelated. If however, the requested specific data is not available fromthe DD for a device or a block of a device but is stored, instead, inthe on-line device, the server 68 sends a command to the smart devicecommunication interface 74 (which may comprise any known smart devicecommunication interface including, for example, a Fieldbus deviceinterface developed by SoftIng, a German company located in Karlsruhe,or the HART device interface of Micromotion, located in Boulder, Colo.)to retrieve the specific data from the on-line device.

The smart device communication interface 74 then sends a request to theDDS 72 for information on how to get the specific on-line device for thedata requested by the server 68. The DDS 72 retrieves this instructioninformation from the DD for the on-line device and returns theinstruction information to the smart device communication interface 74which, in turn, sends a proper request to the on-line smart device. Thesmart device then responds with a data stream including the specificdata. The smart device communication interface 74 then sends a requestto the DDS 72 for information on how to interpret the data streamreceived from the on-line smart device. The DDS 72 then retrievesinterpretation instructions from the DD for the on-line smart device andreturns them to the smart device communication interface 74 which, inturn, interprets the data stream from the on-line device in accordancewith the interpretation instructions in order to extract the specificdata requested by the server 68. The smart device communicationinterface then returns the specific data to the server 68 which providesthe retrieved data to the OLE object with which that data is associated.

The process of writing data to an on-line device is similar to theprocess of reading data from that device except that the server 68 firstsends a request to the DDS 72 for write information, e.g., whether thedata is writable, what type, specific values and range of data can bewritten, etc. If the data is writable, the server 68 sends a writecommand to the smart device communication interface 74 which, in turn,interfaces with the DDS 72 for write protocols for the on-line deviceand sends the proper write command to the on-line device in response tothe information. The smart device communication interface 74 can alsointerpret other data from the on-line devices, such as writeverifications, response codes, data or value changes which occur in thedevice, etc. and sends such data to the server 68 for storage in theproper OLE object.

In some instances, the DDS 72 will inform the server 68 that it needsmore information to answer a request for data. For example, the DDS 72may determine that the handling property of a parameter (i.e., whetherthe parameter is readable and/or writable) is dependent on the modeparameter of a particular device. The DDS 72 sends a request to theserver 68 for the mode parameter of the device. In response thereto, theserver 68 sends a request for the mode parameter of a device to thesmart device communication interface 74 which operates as describedabove to retrieve the mode parameter of the device. When the server 68receives the mode parameter of the device from the smart devicecommunication interface 74, it sends this information to the DDS 72which, thereafter, determines the handling property of a parameter of adevice and returns such property to the server 68 which, in turn, placesthat value in the proper OLE parameter object.

Communication between the server 70, the DDS 72 and the FMS databaseinterface 80 is similar to that described above, except that the FMSdatabase interface 80 is programmed to read and write information to andfrom the FMS database 40 instead of a smart device. Generally, however,the FMS database interface 80 mimics the functions of the smart devicecommunication interface 74 as they relate to communications between theDDS 72 and the server 70.

It is possible to have the FMS database interface 80 store informationpertaining to, for example, values associated with off-line devices anddata pertaining to changes made to on-line and off-line devices in thedatabase 40 in a DDL format, i.e., in a format that mimics how such datais stored in on-line devices. In such a situation, the FMS databaseinterface 80 may need to access the DDS 72 to determine how the data isstored in the FMS database 40. For example, in some instances, thedatabase 40 stores parameter values, such as past parameter values inorder to, for example, mimic the state of a device. Consequently, theFMS database interface 80 may have to access the DDS 72 to retrieve thisinformation to know what type of data is stored in the database, i.e.,integer, enumerated, etc. However, information stored in the database 40need not be stored in a DDL format. Therefore, to service. a commandfrom the server 70 to read data from, or write data to, the database 40,the FMS database interface 80 may not need to access the DDS 72 fordevice values. Instead, the FMS database interface 80 may write data to,and read data from, the database 40 directly.

The FMS database interface 80 is preferably an application programinterface (API) of any conventional type which is specifically set upand configured for retrieving information from the database 40 accordingto any desired or known method. Thus, the FMS database interface 80automatically keeps track of where and how data is stored in, andretrieved from the database 40.

As indicated above, the current application 56 and, if desired, theinterface block 58 can also interface with the database 40 through theFMS database interface 62 and the ODBC block 64. The FMS databaseinterface 62 may comprise any desired or known applications programinterface (API) having a library of routines developed to convert dataand requests from a format recognizable or used by the currentapplication 56 into a form recognizable and usable by the ODBC block 64and vice-versa.

FIGS. 3 and 4A-4C illustrate a particular hierarchy of OLE objects whichhas been developed to represent all of the information defined within oravailable from one or more DDL's, a set of smart devices which followthe protocols of those DDL's and a database which stores informationrelated to devices using those DDL's. The hierarchy of FIGS. 3 and 4A-4Calso represents the relationships between those OLE objects. Thishierarchy can be used within an OLE environment to enable an applicationto retrieve information associated with a DDL, smart devices which usethat DDL, and a database which stores information pertaining to smartdevices which use that DDL. Thus, the hierarchy of FIGS. 3 and 4A-4Crepresents not only an arrangement of DDL information (i.e., informationavailable from DD's of DDL's and/or information available from a deviceor a database associated with devices using one or more DDL's), but alsoa way of defining a communication interface between the DCI 60 and theservers 68 and 70 of FIG. 2 in order to access, retrieve, and changethis information.

Each of the OLE objects in the hierarchy of FIGS. 3 and 4A-4C ispreferably an OLE automation object and is represented as an oval havingthe type of OLE object identified therein. Each of the OLE objects ofFIGS. 3 and 4A-4C includes, or is associated with, a subset of theinformation defined within or used by one or more DDL's and availablefrom DD's, smart devices and databases which store informationpertaining to smart devices.

Generally, each of the OLE automation objects of FIGS. 3 and 4A-4Cincludes properties (or attributes), methods and interfaces. Because theOLE objects within FIGS. 3 and 4A-4C are automation objects, they havean IDispatch interface (a well-known interface of the OLE protocol)associated therewith. The IDispatch of the OLE automation objects ofFIGS. 3 and 4A-4C can be used by, for example, the DCI 60 and the servernetwork 66 to retrieve information pertaining to the properties and themethods of that OLE object and co communicate with other OLE objects.

The properties of an OLE object comprise data pertaining to the objects.Each property also has functions which can be used, for example, to getthe property value and to set the property value of the OLE object.Example OLE object properties include the name of the object, a count ofthe number of items within or associated with the object, a labelassociated with the object, and help associated with the object.

OLE object methods perform actions on OLE objects, or on the data in OLEobjects, implement particular routines using the data in OLE objects,and communicate with other OLE objects. For example, a method mayenumerate a set of values in other OLE objects. Together, the propertiesand the methods of an OLE automation object define the programmableinterface of that OLE object accessible by the server network 66 and theDCI 60.

The hierarchy of FIGS. 3 and 4A-4C comprises an upper hierarchy,illustrated in FIG. 3, and a lower hierarchy, illustrated in FIGS. 4A-4CThe upper hierarchy of FIG. 3 corresponds to and illustrates thephysical or defined connectivity of devices such as HART, Fieldbus, andother smart or conventional devices, and blocks, such as Fieldbusblocks, connected within a process. The lower hierarchy of FIG. 4A-4Cillustrates relationships among the data which is available from, orreferenced by, DDL's such as the HART and Fieldbus DDL's, and the datawhich is stored in and/or available from DD's, smart devices and/or adatabase pertaining to smart or other devices.

The OLE objects of the hierarchy of FIG. 3 and 4A-4C are based oncategories of information found in the Fieldbus DDL. The specificrelationships between these categories and the Fieldbus protocol isdescribed in detail in U.S. patent application Ser. No. 08/599,371,entitled "System and Method for Managing a Transaction Database ofRecords of Changes to Field Device Configurations" filed Feb. 6, 1996,which is assigned to the assignee of the present application and whichis hereby expressly incorporated by reference herein. It should berecognized, however, that the OLE objects of FIGS. 3 and 4A-4C similarlyhave functionally equivalent types of data, definitions, and constructsavailable in other DDL's, such as the HART DDL, and that the hierarchyof FIGS. 3 and 4A-4C therefore can be applied to any DDL.

As noted above, the OLE objects of FIGS. 3 and 4A-4C have been developedto map onto and represent the data available from or defined by theFieldbus and HART DDL's. Thus, for example, the Block object of FIG. 3represents and corresponds to the block entity recognized and used bythe Fieldbus DDL, while the Device object of FIG. 3 and the Parameterobject of FIG. 4A represent and correspond to the device and parameterentities, respectively, recognized and used by both the HART andFieldbus DDL'S.

Each OLE object within the hierarchy of FIGS. 3 and 4A-4C can beaccessed or defined by traversing a path through the hierarchy to thatOLE object. Beginning at the top of FIG. 3, every path through thehierarchy of FIGS. 3 and 4A-4C includes a Root object. Root objectsdefine, among other things, the ViewTime to which the data within any ofthe OLE objects below the Root object pertains. More specifically, theRoot object is associated with a ViewTime, which may be "past,""present," or "future" and, in some instances, which specifies aparticular time. If the ViewTime is present, the time is the actualtime. If the ViewTime is past, the time may be set to any historicaltime but, preferably, is set to a time at which a change was made to oneor more parameter values. Preferably these changes are stored in thedatabase 40 in, for example, an event log. If the ViewTime is future,the time may be set to any future time or may be set to indicate onlythat it refers generally to the future.

The Item method of the Root object includes a set of collections, asidentified in the OLE Object Definitions table, which defines the nextlayer in the hierarchy of FIG. 3. Generally, the collections of the Itemmethod of an OLE object define interconnections between that OLE objectand the OLE objects below that OLE object within the hierarchy of FIGS.3 and 4A-4C. Each collection of an Item method of an OLE object isillustrated in the hierarchy of FIGS. 3 and 4A-4C by the quoted name ofthat collection below the OLE object which includes that collection. Thegeneric name of the members within a collection are identified in thehierarchy of FIGS. 3 and 4A-4C by unquoted and underlined expressionslocated beneath the OLE object associated with the collection type andabove the OLE object which has information pertaining to this expressionas one of the properties thereof.

Thus, for example, the Root object has a collection of BlockTag objects(identified as the "BlockTag" collection), each of which has aparticular name illustrated generally in FIG. 3 as Block Tag. Generally,a block tag is a unique identifier assigned to a particular block withinthe FMS system by a technician installing/configuring the FMS system inorder to identify a particular block. A BlockTag object having a name ofBlock Tag, therefore, uniquely defines a Block object, as illustrated inFIG. 3. As is evident, the actual number of BlockTag objects within thehierarchy of FIGS. 3 and 4A-4C is dependent on the number of blocks (asthat name is used in the Fieldbus DDL protocol) connected to orassociated with the FMS system 10.

The PhysicalTag, DeviceID, and DeviceTag objects relate to or areassociated with the "PhysicalTag," "DeviceID," and "DeviceTag"collections of the Root object, respectively, and are used to uniquelydefine a particular device connected to or associated with the FMSsystem 10. A device ID typically includes a triplet of informationcomprising the name of the device manufacturer, the model number of thedevice, and the serial number of the device. Device tags and physicaltags usually refer to a location of the device in a plant or a processsuch as the process 12. The value of a physical tag and/or a device tagcan be, for example, an alphanumeric code associated with a specificphysical location in the plant or any other description of a physicallocation. For HART devices, the physical tag is considered the same asthe device tag whereas, for Fieldbus devices, the physical tag can havea different value than the device tag. The OLE objects in FIGS. 3 and4A-4C immediately below a quoted collection name, such as thePhysicalTag object, the DeviceTag object, and the DeviceID object, arealso referred to as collections because they are related to constructswhich a DDL considers or defines as collections.

In lieu of, or in addition to having a device tag, a physical tag and/ora device ID, a device can be identified by its physical communicationconnection to an FMS system. Specifically, each device is connected toan FMS network (illustrated in FIG. 3 by the Network object which is a"Net" collection of the Root object) through one of a number ofnetworks, each or which is identified generically by the expressionTCP/IP Node Name.

Each network includes a series of nodes, identified in FIG. 3 by theNetNode object. A network node includes a set of ports (illustrated bythe Port object) which may have names of, for example, "Com1" or "Com2".The port may connect to a device through a modem (identified by theModem object) and at one of sixteen station addresses, each of which isidentified by a different Station Address.

The port of a network node may also connect to a device through one ormore HART interface units (HIU's) (identified by an HIU object) having aStation Address. Each HIU includes one or more interchanges (identifiedby the Interchange object) each of which typically includes 8 linesidentified by Line Number. Interchange objects also include a method(which, contrary to the above-stated general rule about quoted names, isidentified by the label. "Block") which returns an interface to theparticular Block object that describes the HIU.

A network node can also be coupled to a device through one or moredifferent DCS's, for example, the RS3, Provox, or other DCS's. AlthoughFIG. 3 illustrates each of these ELS connected through a generic DCSobject, the actual connection to an RS3 DCS, for example, would be madeand could be identified in FIG. 3 by a node number, a card number, aport (typically one of four ports in a card) and a line (typically fourlines per port). However, because the configurations of these DCSsystems are not yet fully developed, the actual connections with eachare not shown and the DCS object is not mentioned in the OLE ObjectDefinitions table.

Furthermore, a network node may be coupled to one or more Fieldbusinterface cards. However, because the Fieldbus devices are not yet beingsold, the exact connection to a device is not yet known and, therefore,this connection is not represented in the hierarchy of FIG. 3. However,such a Fieldbus connection could easily be added by showing a Fieldbusobject and any other OLE objects related to the components required fora Fieldbus connection from between a network node and a device betweenthe NetNode object and the Device object.

Once a device is identified in any manner specified above, a blockwithin the device can be uniquely determined by the "Tag" collection,illustrated as the Tag object, having the HART Tag name. If the deviceis a HART device, the contents of which are represented by only oneconceptual block, the block is already uniquely identified and cansimply be specified by the "HART" collection. The names of the tagsrelated to the Tag object are specified as HART Tag in FIG. 3 becausethe HART tag of HART devices is used as this identifier. However, othertags for other types of devices could be used instead.

As suggested above, a Block object and, correspondingly, a block of aprocess, can be uniquely identified by traversing any of the abovedefined paths through the upper hierarchy of FIG. 3. Likewise, everyother OLE object within the hierarchy of FIGS. 3 and 4A-4C can beidentified by a unique moniker derived by traversing a path from theRoot object at the top of tile hierarchy of FIG. 3 through to theparticular OLE object. Thereafter, the properties and methods of any ofthe OLE objects within the hierarchy of FIGS. 3 and 4A-4C can bereferenced and obtained using the moniker developed for that OLE object.

More particularly, a moniker can be determined from the hierarchy ofFIGS. 3 and 4A-4C by compiling a string comprising the quoted and theunquoted/underlined expressions encountered in traversing a path fromthe Root object in FIG. 3 to the OLE object of interest, and separatingthese expressions with an exclamation point ("|"). For example, themoniker for a Block object can be any of the following:

Root|BlockTag|Block Tag|

Root|PhysicalTag|HART Tag|Tag|HART Tag

Root|DeviceID|Unique Identifier|HART

Root|Net|TCP/IP Node Name|Port

Name|Modem|Station Address|Tag|HART Tag

As will be evident, monikers for other OLE objects illustrated in FIGS.3 and 4A-4C can be developed using this format. The "NamedConfig"collection of the Root object of FIG. 3 (represented by the NamedConfigsobject) relates to objects which are stored in the FMS database 40 andwhich are not available from a device. Each NamedConfigs object isidentified by a ConfigName to specify a particular NamedConfig object. ANamedConfig object may include, for example, a "recipe" or particularconfiguration of a block necessary for implementing a particularfunction within a process, a past configuration of a block within aprocess, or for that matter, any other desired user information relatedto Block objects. However, to the server network 66 of FIG. 2, each.NamedConfig object looks similar to a Block object except that theparameter value data of a NamedConfig object is retrieved from the FMSdatabase 40 as opposed to being retrieved from a device. NamedConfigobjects may have a subset of the information typically associated with aBlock object.

The lower hierarchy of FIG. 4A-4C illustrates an inter-relationshipamong the data associated with each block of a system. Therefore, asillustrated in FIG. 4A-4C, each Block object (and each NamedConfigobject) includes a set of, collections denominated "Param," "Unit,""Database," "Refresh," "ItemArray," "Collection," "Menu," "Method,""EditDisplay," and "WAO," each having an associated (although slightlydifferently named) OLE object. Each of these OLE objects, in turn, haveother OLE objects related thereto as defined in FIGS. 4A-4C. Thus, forexample, a Parameter object identified by a Param Name may be aVariableParameter object, a RecordParameter object or an ArrayParameterobject. If it is a VariableParameter object, it includes collections of"IndexedItemArray," "Enum," "PreEdit," and "PostEdit," all havingassociated OLE objects. The EnumerationValues object (a collection ofthe VariableParameter object for variables of the enumerated type) hasparticular enumerated values identified by the Enumeration Value objectwhich, in turn, includes a collection of Method objects. These Methodobjects may, for example, include methods of getting or changingenumerated values of a VariableParameter object.

The property, data, and methods stored in, or associated with, all ofthe OLE objects within FIGS. 4A-4C, except for the DatabaseParametersand DatabaseParameter objects, represent information which is availablefrom or through the use of DD's or a device conforming to a DDL. Thedata and method of the DatabaseParameters objects and DatabaseParameterobjects are stored in a database.

As with FIG. 3, any OLE object in FIGS. 4A-4C can be uniquely identifiedby a moniker developed by tracing a path from the Rcot object of FIG. 3down to the particular OLE object of interest. Thus, for example, themoniker for a pre-edit Method block could be constructed by adding ontothe end of the moniker for any Block object of FIG. 3, which is alsorepresented by the Block object of FIGS. 4A-4C the expression|param|Param Name|PreEdit|Index.

Once a moniker is established for a particular object within thehierarchy of FIGS. 3 and 4A-4C and stored in the memory associated withthe server network 66, the DCI 60 and the server network 66 can,thereafter, operate on and access that OLE object using a shorter unique"handle" generated by the server network 66. The handle may, forexample, comprise a unique number identifying an OLE object which hasbeen stored in the memory of the server network 66.

In essence, with a unique moniker or the handle, any OLE objectidentified by the hierarchy of FIGS. 3 and 4 can be immediately accessedby the DCI 60 or the server network 66 and the methods within that OLEobject can be invoked in order to accomplish communication with the DDS,a database, a smart device, or other OLE objects as necessary. Thus, forexample, the software routine within the server 68 which accesses theDDS 72 to retrieve a particular parameter value from a particular devicecan be initiated when a call to the proper VariableParameter object isinitiated by the DCI 60 using a command which tells the OLEVariableParameter object to read a parameter value.

As is evident, the server network 66 communicates with the database 40,the DDS 72, and the on-line devices transparently to the DCI 60 and thecurrent application 56, because the server network automaticallyaccesses the interrelationships between the OLE objects identified bythe lower hierarchy of FIG. 4 to determine which set of routines toimplement in order to obtain new information requested by an OLE objector a DDS.

It should be noted that, for any OLE object of FIGS. 3 and 4A-4C to beaccessed, the OLE objects above that OLE object in at least one pathbetween that OLE object and the Root Object FIG. 3 must be stored in theserver network memory. Thus, for example, when accessing aVariableParameter object of a parameter for a block, the Parameterobject and the Block object associated with that parameter and thatblock will also be stored in the server network memory. The Deviceobject, the DeviceID object and the Root object may also be stored inthe server network memory. Without these higher level objects, theserver network 66 can not access enough information to determine how tolocate and retrieve the data of the VariableParameter object.

As will be apparent to those skilled in the art, the DCI 60 may operateto communicate with and retrieve information from the OLE hierarchyrepresented by FIGS. 3 and 4A-4C by performing relatively simpleroutines which, for example, (1) create an object hierarchy andassociate it with the server network 66, (2) traverse the objecthierarchy to explore the objects below a specified object, (3) implementstandard OIE methods like Item, which traverses a specific path from oneobject to another, and NewEnum, which creates an interface to enumerateobjects one level below, (4) implement methods related to Block objectswhich may include methods related to DDL operations, (5) read and writeRoot and Device object properties, (6) initiate and control non-blockingread and write requests from OLE objects, (7) retrieve results fromblocking reads and writes, (8) control changes to the database 40, and(9) control the creation and maintenance of an event log that includesinformation pertaining to, for example, user changes to the systemincluding change times, identification of the persons and the computerswhich made the changes, etc.

As a result, an application for the FMS system 10 does not have to bespecifically programmed to interface with a DDS, database or smartdevices which, in turn, allows an application developer to be much lessknowledgeable with respect to DDL formats, DD's and smart devicecommunications.

It will be noted that, using the hierarchy of FIGS. 3 and 4A-4C asdescribed above, any application implemented by the FMS system 10 caninterface with FMS devices using, for example, any OLE-compatibleprogramming environment to gain access to the IUnknown and IDispatchinterfaces associated with each object in the hierarchy. It isconsidered that Visual Basic programs and C++ programs are well-suitedto use the above-defined OLE hierarchy.

Furthermore, although the hierarchy of FIGS. 3 and 4A-4C is specificallyrelated to the Fieldbus DDL and to the HART DDL, which is very similarto the Fieldbus DDL, it is considered that this or a similar hierarchycan be made for other DDL's associated with other smart devicesincluding, for example, Modbus smart devices in accordance with thepresent invention. Furthermore, it is considered that the hierarchy ofFIGS. 3 and 4A-4C can be implemented by other object-orientedprogramming protocols and even by non-object oriented programmingprotocols.

The functionality of the interface block 58 will now be described inmore detail. As noted above, during operation, the current application56 calls the interface block 58 to initialize one or more specificcontrols which, thereafter, automatically handle all operationsassociated with interfacing between the Windows operating system 49, thesmart devices within the process 12 and/or the FMS database 40 withrespect to a device, a block, or a parameter associated with the process12. The interface block 58 may also change the Time property of the Rootobject stored in the memory of the server network 66 to control displaysin an advantageous manner.

Each control of the interface block 58 displays and updates informationpertaining to a devIce, a block, a parameter, or a time on the display30; communicates with the smart devices, the database 40, and the servernetwork 66 in response to user or application inputs to retrieve datafrom, or write data to, the DDS 72, the smart devices, the database 40,or the Root object in the server network 66, without further involvementof the current application 56. Importantly, once established, a controlgenerally appears to run independently of the current application 56 andof other controls which may have been established.

As illustrated in FIG. 5, the interface block 58 includes a mastercontrol routine 300 which can be used to implement control functions,including control functions relating to a device, a block, or aparameter associated with the process 12. The interface block 58 alsoincludes a master timeline control routine 301 which can be used toimplement control functions such as reading and writing times from theRoot object and changing time values from the database 40.

When the current application 56 calls the interface block 58 toimplement a device, block, parameter or timeline control, one of themaster control routines 300 or 301 is, in effect, copied and convertedinto a specific control routine or control. Such specific controls areillustrated in FIG. 5 as a device control 302, a block control 304, aparameter control 306 and a timeline control 308. The specific controls302, 304, 306, 308 thereafter automatically handle functions related tocommunication between the Windows operating system 49, the currentapplication 56, the database 40 (through the DCI 60), the DDS 72(through the DCI 60), and the on-line smart devices (through the DCI 60)as those communications relate to the specific devices, blocks,parameters, or timelines for which the controls are created. Onceestablished, each of the controls 302, 304, 306, 308 operatescontinuously and independently of the other controls and the currentapplication 56. Any number of the same and/or different control typescan be implemented to operate at the same time.

While FIG. 5 illustrates the controls 302, 304, 306, 308 as separateroutines which are copies of one of the master control routines 300 or301, controls 302, 304, 306, 308 can also contain the data necessary toimplement a particular device, block, parameter, or timeline controlusing one of the master control routines 300 or 301.

FIG. 6 generally illustrates the steps that should be performed by, forexample, the current application 56 to initialize a control, includingany of the controls illustrated in FIG. 5. A block 310 defines the typeof the control, for example, a device, a block, a parameter, or atimeline control, by providing the interface block 58 with a uniquemoniker pointing to the OLE object within the hierarchy of FIGS. 3 and4A-4C with which the control is associated. Because, conceptually, aninstantiation of the hierarchy of FIGS. 3 and 4A-4C exists for each timeavailable to the FMS application, the timeline control specifies theRoot object of a particular hierarchy by specifying, for example, thetime and view of the Root object with which the control is associated.

A block 311 defines the user interface attributes including, forexample, the fonts, sizes, etc., of display characters, the style inwhich the information is to be displayed, the display screen location atwhich the control information is to be displayed, the initial windowsize of the control display if the size of a control display is capableof being changed by the user, and the so-called "visibility" of thecontrol. Control visibility defines whether the control will actually bedisplayed or be visible on the screen. While an invisible control stilloperates to retrieve data from its associated OLE object and may providesuch information to the current application 56, the user interfaceoperations of that control are simply disabled.

A block 312 defines the refresh rate of the control (i.e., the rate atwhich the control will receive information from its associated OLEobject in a periodic read). In effect, the block 312 connects thecontrol to a particular Root object of the hierarchy in FIGS. 3 and4A-4C, and the Root object defines the rate at which the OLE object willrefresh data in response to a periodic read.

FIG. 7, illustrates the general operation of a control routine which canbe used for the device control, the block control, the parameter controland the timeline control of FIG. 5. A block 313 connects to orestablishes a connection to the proper OLE object as defined by thehierarchy of FIGS. 3 and 4A-4C and the moniker provided by the currentapplication 56. Specifically, the control sends a command through theDCI 60 to the server network 66 to read information, for example, theproperties, of the OLE object associated with the control. Preferably,this command is a periodic read which tells the OLE object, such as adevice, a block or a parameter object, to periodically send therequested data to the control.

In response to the read, the server network 66 establishes a connectionto the OLE object by retrieving the data thereof from the DDS 72, thesmart devices and/or the database 40, and stores that data as the OLEobject in a server network memory. To perform this read function,however, the server network 66 must also store in its memory the datapertaining to the Device and/or Block objects above the requested OLEobject as defined by the hierarchy of FIGS. 3 and 4A-4C. When stored inthe server memory, the requested OLE object data is sent to the DCI 60and then to the interface block 58 where this data may be stored in amemory or control cache associated with the interface block 58.

A block 314 then establishes or initializes a user interface screen onthe display 30 for the particular control as defined by the userinterface attributes provided to the control by the block 311 of FIG. 6.The display attributes may be configured to display control informationin any desired manner using standard Windows calls and Windows formats.An exemplary screen for each of the device, parameter, block, andtimeline controls is illustrated in FIGS. 14-17.

Next, a block 315 checks to see if any messages have been received fromthe application, the user interface via the Windows operating system 49,or an OLE block through the DCI 60. If no such messages have beenreceived, the block 315 continually rechecks for such messages. When theblock 315 receives a message, control is transferred as indicated by theidentifiers labeled 1, 2, and 3.

FIG. 8 illustrates the operation of a control in response to a messagefrom the current application 56. A block 316 interprets the messagewhich can be of three general types, including a read OLE object datamessage, a charge Parameter object value, or a Root object value messageand a change user interface message. In response to a read OLE objectdata message, a block 318 reads the requested data from the referencedOLE object of FIGS. 3 and 4A-4C. For example, a device control may readthe DeviceID property or the "Tag" collection of a Device object while ablock control may read the Name property or the "Param" collection of aBlock object. A parameter control might read parameter properties suchas the value or name of a VariableParameter object. A timeline controlcan read Root object properties and may obtain a list of times for whichRoot objects exist in the past from the database 40. Thereafter, theblock 318 returns control to the block 315.

In response to a change-parameter or root-value message, a block 320implements a change to the referenced parameter object, for example, theVariableParameter object, RecordParameter object, or ArrayParameterobject of FIG. 4A-4C and returns control to the block 315. In responseto a change-user-interface message, a block 322 implements a change ofthe user interface and returns control to the block 315.

FIG. 9 illustrates a routine 324 which is implemented by a controlduring a read OLE object data procedure. Specifically, a block 326 sendsa message through the DCI 60 to the OLE object associated with thecontrol to retrieve data from that OLE object. Thereafter, a block 328determines what type of read message was received. If a non-blocking,non-periodic or a non-blocking, periodic read message was received, theblock 328 returns control to the block from which the routine 324 wascalled. A non-blocking read refers to one in which the control sends aread message to the OLE object associated with the control and does notwait for a response from the OLE object before continuing with otherfunctions. A non-periodic read is a request for a single, one-time readfrom the OLE object associated with the control. A periodic readinstructs the OLE object to periodically notify the control of changeswhich occur to data within the OLE object at a rate defined within theRoot object associated with that OLE object.

If, however, the read was a blocking read, which is always anon-periodic read, a block 330 waits for the return data requested fromthe OLE object. Next, a block 332 stores the received OLE object data inthe control cache. If necessary, a block 334 changes the user interfaceby calling a user interface change routine described hereinafter toreflect the new data obtained by the read. A block 336 notifies thecurrent application 56 if the application has identified that it wantsto receive messages or data changes from OLE object data reads during,for example, initialization of the control. Thereafter, control isreturned to whatever block called the routine 324.

FIG. 10 illustrates a routine 338 which is implemented by a controlduring a change of a parameter or root value of an OLE parameter object(such as the VaribleParameter object) or a Root object. A block 340determines whether the parameter or root value indicated to be changedis writable. In essence, the block 340 sends a message to read thehandling properties of the OLE object and determines whether theparameter value is writable. If the block 340 determines that theparameter or root data value is not writable, a block 342 notifies theuser or the current application 56 that the parameter or root value isnot writable, such as by calling the change-user interface routinedescribed below. Thereafter, control is returned to the block from whichthe routine 338 was called.

If, on the other hand, the block 340 determines that the parameter orroot value is writable, a block 344 determines if the new parametervalue (or root value) is an accepted value. To perform this function,the block 344 reads, for example, the value characteristics of theparameter object associated with the control such as the minimum value,the maximum value and the type of value accepted which may be, forexample, a variable, an enumerated set, etc. If, thereafter, the block344 determines that the new value is out of range or of the wrong type,a block 346 may send a message to the application and/or may change theuser display to indicate that an unacceptable value has been entered.Thereafter, control is returned to the block which called the routine338.

If the block 344 determines that the new value is an accepted value fora parameter or a root object, a block 348 sends a change message to thecorrect OLE parameter or root object through the DCI 60. The new valueis then changed in the OLE object which, of course, may cause acorresponding change in a smart device or in the database 40.

A block 350 waits for a return message and a block 352 decodes thereturn message to determine if the write was successful. If the writewas successful, a block 354 may indicate to the application and/or tothe user via the user interface that the change was made (e.g., bychanging the color of the background of the data on the screen).

If the block 352 determines that the write was not successful, a block356 indicates to the application and/or to the user via the userinterface that the change was not made (e.g., by changing the data onthe screen to its original state). Incidentally, the response codesassociated with an OLE object are always available to an application sothat the reason for the rejection can be determined and/or displayed tothe user.

If the block 352 determines that the change was made but that a writecondition exists, a block 358 retrieves a response code from the OLEobject by specifically initiating a proper read from the OLE object. Ablock 360 then indicates to the application, and/or to the user ifdesired, that the change was made but that a write condition exists. Theblock 360 may also indicate the type of condition that exists (e.g.,that the OLE object property was set to the nearest available possiblevalue). Each of the blocks 354, 356, and 360 returns control to theblock which called the routine 338.

FIG. 11 illustrates a routine 362 which is implemented by a control tochange the user interface display. A block 364 changes the displayinterface attributes in conjunction with new attributes provided by thecurrent application 56, or in accordance with a set of attributespreviously defined by the control for the condition which now exists.These previously defined attributes may be stored in a memory associatedwith the control, such as the control cache. A block 366 refreshes theuser display using the new user display attributes and the data in thecontrol cache which is to be displayed. Thereafter, control returns tothe block from which the routine 362 was called.

FIG. 12 illustrates the operation of a control in response to a messagefrom the user interface. A block 370 checks to determine if the useraction is meaningful. The block 370 may, for example, determine if theuser clicked the proper button of the mouse or if the pointer (i.e., thecursor or arrow) was located within an area of the control display wherethe control :recognizes the user's actions as requests for action. Ifthe user action is not meaningful, a block 372 simply ignores the useraction or gives some indication that the action has been ignored (e.g.,refreshing the user display with the same display interface attributes).Thereafter, control is returned to the block 315.

On the other hand, if the user action is meaningful, a block 374interprets the message from the user interface. If the message from theuser interface indicates that the user would like to change a parametervalue or a root value, a block 376 calls the change-parameter/root-valueroutine 338 and then returns control to the block 315. If desired theblock 376 may also change the user interface, for example, to implementa color change to the background field surrounding the data to bewritten. Upon receiving an indication of a successful write, the block376 may also return the background color to its original state toindicate that the value has been written (if the routine 338 has notalready done so).

If, on the other hand, the block 374 determines that the user isrequesting a change in the user interface, a block 378 calls thechange-user-interface routine 362 and returns control to the block 315.

FIG. 13 illustrates the operation of a control in response to a messagefrom the DCI 60, i.e., from an OLE object within the hierarchy of FIGS.3 and 4A-4C block 380 first determines if the message from the DCI 60 isnon-blocking read return or if the message indicates some other changeor changed condition within the referenced OLE object of the OLEhierarchy. A condition-change message may, for example, comprise an FMSlocking message which prevents multiple users from accessing aparticular block within a device of a process at the same time. If, forexample, a block is being accessed by a different user by a hand-heldcommunicator or another FMS system attached to the device, the OLEobject will identify such condition to the control through the DCI 60.Thereafter, the control may indicate to the user that the data of thatblock is no longer writable by, for example, displaying a graybackground on the screen surrounding a normally writable value.

In the case of a non-blocking read return, a block 382 determines if thereturned value has changed. If so, a block 384 stores this new value inthe control cache. The block 384 and, if there has been no change in thedata stored in the control cache, the block 382 provides control to ablock 386. The block 386 is also implemented if the block 380 determinesthat the message from the OLE object relates to a change not related toa non-blocking read.

The block 386 determines if a change to the user interface is needed,such as if the changed data or the new condition or status is to bedisplayed on the screen. If so, a block 390 calls thechange-user-interface routine 362 to display the changed data or thecondition to the user. If, however, the block 386 determines that thechanged data or the condition does not need to be displayed, or if theblock 390 has indicated such changed data or condition to the user, ablock 392 determines if the application should be notified of thechanged data or condition in accordance with pre-written instructions.If so, a block 394 sends a message to the current application 56indicating the changed data or condition. Thereafter, control isreturned to the block 315.

Generally, information accessed by a device, a block, a parameter, or atimeline control can be displayed on a screen in any desired mannerincluding (1) the EDIT style wherein the control behaves similarly to anormal Microsoft Windows Edit control, (2) the COMBO style wherein thecontrol behaves similarly to a normal Microsoft Windows Combo Boxcontrol (i.e., as a drop down list), (3) the LIST style wherein thecontrol behaves similarly to a normal Microsoft Windows List Box control(i.e., such that each item in the enumeration will be represented as alist box entry), (4) the GROUP style wherein the control behavessimilarly to a normal Microsoft Windows Group Box control, or (5) thePANEL style wherein the control displays either a raised or a sunkenpanel and/or any other desired style or format.

FIG. 14 illustrates control displays 400 and 402 associated with twodevice controls. Each of the device control displays 400 and 402includes a picture or digital bitmap of the device (usually provided bya device manufacturer or the DDS provider), which is stored in a memoryassociated with the current application. Instead, this bitmap may bestored in the database 40 so as to be accessible by the OLE objects.

The control displays 400 and 402 may include any other desiredinformation about a device including, for example, the name (illustratedin FIG. 14), tags, moniker, etc. of a device, or any other desireddevice-specific information. Furthermore, menus for the device can beprovided in a pull-down window associated with the device controldisplays 400 and 402. Such menus may include files associated with adevice, for example, the names of the collections associated with aDevice object for the device, methods which can be implemented on thedevice, including calibration, resetting, and self-testing methods,blocks associated with the device, a list of parameters associated withthe device, help for the device, service notes for the device, etc.Other information about a device which may be displayed includes thecontents of every variable of each parameter in a device, the face-plateinformation of a device, the operational status of the device,including, for example, whether an error has occurred within the deviceand a side-by-side list of, for example, the values of variables of oneor more parameters of a device as they exist or existed at specifiedtimes.

FIG. 15 illustrates a general parameter control display 406 along withparticular parameter control displays 408, 410, and 412 associated withthree specific parameter controls for the parameters of a device. Eachof the parameter control displays 406-412 is located at a differentportion on a screen and, in particular, the parameter control display406 is located at the top of the screen while the parameter controldisplays 408, 410 and 412 are located in sequence below the parametercontrol display 406.

The parameter control display 406 illustrates that a parameter controldisplay may have three fields, including a label field, which providesinformation pertaining to the type of information being shown, forexample, "Pressure," "Temperature," or "Mode," a value field which showsthe value of a parameter and a units field which indicates the units inwhich the value is expressed. The value of a parameter can be an integernumber, a decimal number (parameter control displays 408 and 410) or anenumerated value consisting of one of an enumerated set of values, aslisted in a pull-down menu associated with the parameter control display412. The parameter control display 412 does not include a units variablebecause such a variable is inapplicable to the enumerated set associatedtherewith.

FIG. 16 illustrates two block control displays 414 and 416 associatedwith block controls. Similar to a device control display, a blockcontrol display typically includes a picture or other representation ofa block and/or any other desired information pertaining to a blockand/or the device in which the block is located including, for example,whether a block is an input, output, or control (or interface) block.

FIG. 17 illustrates two timeline control displays 420 and 422 which areused to control and change the time and view properties of OLE Rootobjects to which other controls, such as device, block, and parametercontrols may be connected. Each of the timeline controls associated withthe displays 420 and 422 can change the time value of its respectiveRoot object to any of the previous times for which Root objects areavailable, which will typically include the past times when changes weremade to the system and for which transaction records are stored in atransaction database of the FMS database 40 (FIG. 1). Furthermore, thetimeline controls associated with the control displays 420 and 422 canchange the view of a Root object between a past, a present, or a futuresetting.

Each timeline control display usually includes, as illustrated in FIG.17, a slider 424 indicating which one of the past, present, and futureviews is selected as well as a combo box 426 which allows a user toselect from a set of historical times, each having, for example, a dateand a time.

By changing the timeline control slider 424, the user tells the timelinecontrol to change the Root object View property associated with thattimeline control. By changing the timeline control combo box 426, theuser tells the timeline control to change the Root object time value toa specified time.

When a timeline control changes the time or view of a Root object, anyother controls, such as parameter, device or block controls which areassociated with that Root object will automatically be updated inresponse to change messages generated by the OLE objects. These changemessages will be generated by the OLE objects when the OLE objectswithin the same hierarchy as the Root object retrieve new datapertaining to the new time or view now associated with the Root object.

FIG. 17 also illustrates temperature and pressure parameter controldisplays 430 and 432 which are connected to the same Root object as thetimeline control associated with the timeline control display 420.Likewise temperature and pressure parameter control displays 440 and 442are connected to the same Root object as the timeline control associatedwith the timeline control display 422. Because the timeline controldisplays 420 and 422 are set to different times, i.e., a past time(control display 420) and the present (control display 422), the valuesof the temperature parameters 430 and 440 are different and the valuesof the pressure parameters 432 and 442 are different. A list of suchparameter control displays can be configured on the screen to displayone or more complete configurations for a device, block, etc. Device andblock and/or other parameter controls can also be associated with thesame Root object as timeline controls and can be used to illustrate aconfiguration display which shows a configuration of a device, a block,or a parameter at different times in a side-by-side or otherrelationship on a screen. A timeline control can also be used inconjunction with other controls on a display to scroll through thesettings or values of devices, blocks or parameters or a set of suchdevice, blocks, or parameters. As is evident, any desired combination oftimeline, device, block, parameter and/or other controls may be used toillustrate any desired past: and or present information to a userincluding, for example, information related to on-line devices at thepresent time, i.e., on-line data, and information related to on-linedevices in the past or future, and to off-line devices in the past,present or future, i.e., off-line data. Furthermore, as indicated withrespect to FIG. 23, the same data, for example, the same parametervalues for a device, may be illustrated for different times usingtimeline controls and, if desired, routines may be implemented toindicate the differences between the sets of values.

The timeline control changes the Time property of the Root object to aspecific time (designated hereinafter as the ViewTime), which the userspecifies using the timeline control. Consequently, the time attributesfor all of the objects downstream of the Root object in the OLEhierarchy are changed to match the ViewTime as described above. Inaddition, the values of other properties of those objects are updated tothe values corresponding to that ViewTime.

For a Block object in particular, the state of the corresponding blockat any desired time (e.g., the ViewTime specified using the timelinecontrol) is obtained using a transaction database. More particularly,the values of the parameters of the Block object at the ViewTime (i.e.,the values of the Value properties of the Parameter objects of the Blockobject as of the ViewTime) are obtained by searching the transactiondatabase in reverse-chronological order beginning at the ViewTime tofind the values last assigned to the parameters corresponding to thoseParameter objects on or before the ViewTime.

FIG. 18 is a flowchart illustrating how a state of a particular blockcan be reconstructed from the transaction database. First, a block 450initializes a set variable {S} to null. The set variable {S} is used toaccumulate the values as of the ViewTime of the parameters of the blockwhose ViewTime state is to be reconstructed. A block 452 then sets atime associated with the state {S} equal to the ViewTime. Thereafter, ablock 454 determines whether the set variable {S} includes a value foreach parameter of the Block Object. If it does, then a block 456 assignsthe assembled state {S} as the state of the block at the ViewTime, andexecution of the state reconstruction routine of FIG. 18 ends.

If the block 454 determines that the accumulated-state (i.e., thecontents of the set variable {S}), does not include values for everyparameter in the block, then a block 458 identifies the next parameter Pfor which a current value is not included in the accumulated state {S}.A block 460 then searches the transaction database inreverse-chronological order beginning at the ViewTime to find thelatest-made change TR made at or before the ViewTime. A block 462 thenadds the parameter P, with the value of the parameter P set by thechange represented by transaction TR, to the accumulated state {S}, andcontrol then returns to the block 454 to check, once again, whethervalues of all parameters in the block have now been accumulated in thestate {S}.

Although the device, block, parameter, and timeline controls areillustrated and described herein, other controls according to thepresent invention could be constructed to illustrate other properties ordata available through DDL, including data within any of the OLE objectsillustrated in FIGS. 3 and 4A-4C.

While the present invention has been described with reference tospecific examples, which are intended to be illustrative only, and notto be limiting of the invention, it will be apparent to those ofordinary skill in the art that changes, additions and/or deletions maybe made to the disclosed embodiments without departing from the spiritand scope of the invention.

We claim:
 1. An interface control adapted for use with a managementsystem having a user interface, a database and a communication networkthat communicates with the database, a field device and a devicedescription associated with the field device, wherein the field device,the device description and the database store a multiplicity of groupsof logically related items of device data, the interface controlcomprising:means for implementing a particular interface control for anindicated group of the multiplicity of groups of logically related itemsof device data including;means for commanding the communication networkto read the items of device data associated with the indicated groupfrom at least one of the field device, the device description, and thedatabase to produce a set of items of retrieved device data for theindicated group, and means for displaying the set of items of retrieveddevice data for the indicated group via the user interface in apredefined format; means for identifying any one of the multiplicity ofgroups of logically related items of device data as the indicated group;and means responsive to the identifying means for invoking theimplementing means to create the particular interface control for theindicated group.
 2. The interface control of claim 1, wherein theimplementing means further includes means responsive to the userinterface for instructing the communication network to implement achange to one of the items of device data associated with the indicatedgroup as the one of the items of device data is stored in the fielddevice or the database.
 3. The interface control of claim 2, wherein theinstructing means includes means for determining if the change to theone of the items of device data associated with the indicated group isallowable and means for indicating, via the user interface, that thechange is not allowable when the determining means determines that thechange is not allowable.
 4. The interface control of claim 3, whereinthe determining means includes further means for commanding thecommunication network to retrieve a range indication associated with theone of the items of device data associated with the indicated group fromone of the device description, the field device and the database and.means for checking to determine if the change to the one of the items ofdevice data associated with the indicated group falls within the rangedefined by the retrieved range indication.
 5. The interface control ofclaim 2, wherein instructing means includes means for determining if thechange to the one of the items of device data associated with theindicated group is completed and means for indicating, via the userinterface, that the change to the one of the items of device dataassociated with the indicated group has been completed.
 6. The interfacecontrol of claim 5, wherein instructing means includes further means forindicating, via the user interface, that the change to the one of theitems of device data associated with the indicated group is in theprocess of being completed.
 7. The interface control of claim 1, whereinthe implementing means further includes means coupled to thecommunication network for recognizing a change in one of the items ofdevice data associated with the indicated group as stored in the fielddevice or the database and means responsive to the recognizing means forindicating the change of the one of the items of device data associatedwith the indicated group via the user interface.
 8. The interfacecontrol of claim 1, wherein the set of items of retrieved device datafor the indicated group comprises data pertaining to the field device,and wherein a first of the set of items of retrieved device dataincludes a pictorial representation of the field device.
 9. Theinterface control of claim 8, wherein a second of the set of items ofretrieved device data includes an indication of the type of the fielddevice.
 10. The interface control of claim 9, wherein a third of the setof items of retrieved device data includes an indication of the locationof the field device with respect to a system in which the field deviceis used.
 11. The interface control of claim 10, wherein a fourth of theset of items of retrieved device data includes a list of informationpertaining to the field device.
 12. The interface control of claim 11,wherein the list includes at least one of methods for implementation onthe field device and parameters associated with the field device. 13.The interface control of claim 1, wherein the set of items of retrieveddevice data for the indicated group comprises data pertaining to a blockof the field device comprising one of an input, an output, or a controlfunction associated with the field device, and wherein a first of theset of items of retrieved device data includes a pictorialrepresentation of the block.
 14. The interface control of claim 13,wherein a second of the set of items of retrieved device data includesan indication of the type of the block.
 15. The interface control ofclaim 14, wherein a third of the set of items of retrieved device dataincludes an indication of the manner in which the block is associatedwith a system in which the block is used.
 16. The interface control ofclaim 15, wherein a fourth of the set of items of retrieved device dataincludes a list of information pertaining to the block.
 17. Theinterface control of claim 16, wherein the list includes an indicationof a set of parameters associated with the block.
 18. The interfacecontrol of claim 1, wherein the set of items of retrieved device datafor the indicated group comprises data pertaining to a parameterassociated with the field device, and wherein a first of the set ofitems of retrieved device data includes a label of the parameter and asecond of the set of items of retrieved device data includes a value ofthe parameter.
 19. The interface control of claim 18, wherein a third ofthe set of items of retrieved device data includes a unit designationassociated with the value of the parameter.
 20. The interface control ofclaim 18, wherein the value of the parameter comprises one of anenumerated list of potential values.
 21. The interface control of claim1, wherein the set of items of retrieved device data for the indicatedgroup comprises configuration data related to the configuration of thefield device at a particular time, and wherein the implementing meansincludes means for changing the particular time associated with the setof items of retrieved device data.
 22. The interface control of claim21, wherein the changing means includes further means for displaying arepresentation of a slider via the user interface and means for allowingmanipulation of the slider to change the particular time.
 23. Theinterface control of claim 21, wherein the changing means includesfurther means for changing the particular time between one of aplurality of times in the past, a present time, and a future time. 24.The interface control of claim 1, wherein the set of items of retrieveddevice data for the indicated group comprises configuration data relatedto two configurations of the field device at two particular times, andwherein the displaying means includes means for changing the particulartime associated with the items of retrieved device data for theindicated group related to one of the two configurations.
 25. A controladapted for use by a management system that includes a user interfaceand that is capable of being coupled to a plurality of field devices,each having a device description associated therewith, the controlcomprising:means for communicating with the plurality of field devicesand the device descriptions to effect communication with respect to amultiplicity of groups of logically related items of device data storedin the plurality of field devices and the device descriptions; means forimplementing a particular control for a particular one of themultiplicity of groups of logically related items of device dataincluding,means for controlling the communicating means to retrieve theitems of device data within the particular one of the multiplicity ofgroups of logically related items of device data to produce a retrievedgroup of items of device data, and means for displaying the retrievedgroup of items of device data via the user interface in a predefinedformat; means for identifying any of the multiplicity of groups oflogically related items of device data as the particular one of themultiplicity of groups of logically related items of device data; andmeans responsive to the identifying means for invoking the implementingmeans to create the particular control for the particular one of themultiplicity of groups of logically related items of device data. 26.The control of claim 25, wherein the implementing means further includesmeans responsive to the user interface for instructing the communicatingmeans to change one of the items of device data within the particularone of the multiplicity of groups of logically related items of devicedata.
 27. The control of claim 26, wherein the instructing meansincludes means for determining if the change to the one of the items ofdevice data is allowable and means for indicating, via the userinterface, that the change is not allowable when the determining meansdetermines that the change is not allowable.
 28. The control of claim26, wherein the instructing means includes means for determining if thechange to the one of the items of device data is completed and means forindicating, via the user interface, that the change to the one of theitems of device data has been completed.
 29. The control of claim 26,wherein the communicating means includes means for recognizing when afurther one of the items of device data changes to a changed item ofdevice data and wherein the implementing means further includes meansresponsive to the recognizing means for automatically illustrating, viathe user interface, the change to the further one of the items of devicedata when the further one of the items of device data is within theparticular one of the multiplicity of groups of logically related itemsof device data.
 30. The control of claim 29, wherein the illustratingmeans includes means for replacing one of the items of the retrievedgroup of items of device data with the changed item of device data viathe user interface.
 31. The control of claim 25, wherein the managementsystem also includes a database that stores items of device data,wherein the communicating means includes further means for communicatingwith the database and wherein the implementing means includes furthermeans for controlling the communicating means to retrieve, as part ofthe retrieved group of items of device data, the items of device datawhich are associated with the particular one of the multiplicity ofgroups of logically related items of device data and which are stored inthe database.
 32. The control of claim 31, wherein the displaying meansincludes means for making the displayed retrieved group of items ofdevice data invisible to a user via the user interface.
 33. The controlof claim 31, wherein the communicating means includes means forcategorizing the items of device data into a predetermined hierarchy ofcategories of device data, each having communication instructions, andwherein the communicating means communicates with one of the pluralityof devices, one of the device descriptions or the database using thecommunication instructions associated with one of the categories of thehierarchy of categories of device data.
 34. The control of claim 33,wherein the categorizing means includes objects in an object-orientedprogramming paradigm.
 35. The control of claim 31, wherein the retrievedgroup of items of device data comprises data pertaining to one of theplurality of field devices, and wherein a first item of the retrievedgroup of items of device data includes a pictorial representation of theone of the plurality of field devices.
 36. The control of claim 35,wherein a second item of the retrieved group of items of device dataincludes an indication of the type of the one of the plurality of fielddevices.
 37. The control of claim 31, wherein the retrieved group ofitems of device data comprises data pertaining to a block comprising oneof an input, an output, or a control function associated with one of theplurality of field devices, and wherein a first item of the retrievedgroup of items of device data includes a pictorial representation of theblock.
 38. The control of claim 31, wherein the retrieved group of itemsof device data comprises data pertaining to a parameter associated withone of the plurality of field devices, and wherein a first item of theretrieved group of items of device data includes a label of theparameter and a second item of the retrieved group of items of devicedata includes a value of the parameter.
 39. The control of claim 38,wherein a third item of the retrieved group of items of device dataincludes a unit designation associated with the value of the parameter.40. The control of claim 31, wherein the retrieved group of items ofdevice data comprises configuration data related to the configuration ofone of the plurality of field devices at a particular time, and wherein.the implementing means includes means for allowing a user to change theparticular time associated with the configuration data.
 41. The controlof claim 40, wherein the allowing means includes means for changing theparticular time between one of a number of past times, a present time,and a future time.
 42. The control of claim 31, wherein the retrievedgroup of items of device data comprises configuration data related tofirst and second configurations associated with one or two of theplurality of field devices at two individual times, and wherein theimplementing means includes means for allowing a user to change theindividual time associated with the configuration data related to thefirst configuration.
 43. The control of claim 42, wherein theimplementing means includes second means for allowing a user to changethe individual time associated with the configuration data related tothe second configuration.
 44. A method of controlling communicationbetween a management system, having a user interface, and a plurality offield devices, each having a device description associated therewith,the method comprising the steps of:providing a generalized interfacingroutine which, for any particular one of a plurality of different groupsof logically related items of the device data performs the stepsof;retrieving the items of device data associated with the particularone of the groups of logically related items of device data as stored inthe plurality of field devices and the device descriptions, displayingthe retrieved items of device data associated with the particular one ofthe groups via the user interface in a predefined format, recognizingwhen one of the items of device data stored in one of the plurality offield devices changes, and indicating, via the user interface, thechange to the one of the items of device data when the one of the itemsof device data corresponds to one of the retrieved items of device dataassociated with the particular one of the groups; and using thegeneralized interfacing routine to perform communication for amultiplicity of the plurality of different groups of logically relateditems of device data.
 45. The method of claim 44, including the steps ofstoring a subset of items of one of the groups of logically relateditems of device data in a database associated with the managementsystem, communicating with the database to retrieve one of the subset ofitems of device data stored in the database as one item of the retrieveditems of device data, recognizing when the one of the subset of items ofdevice data stored in the database changes and indicating, via the userinterface, the change to the one of the subset of items of device datastored in the database.
 46. The method of claim 45, further includingthe step of changing a particular one of the items of device data storedin the field device or the database corresponding to a particular one ofthe retrieved group of items of device data in response to user input.